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1 SECURE DISK DRIVE COMPRISING A SECURE DRIVE KEY AND A DRIVE ID FOR 

2 IMPLEMENTING SECURE COMMUNICATION OVER A PUBLIC NETWORK 

3 

4 BACKGROUND OF THE INVENTION 

5 

6 Field of the Invention 

7 The present invention relates to disk drives for computer systems. More particularly, the 

8 present invention relates to a secure disk drive comprising a secure drive key and a drive ID for 

9 implementing secure communication over a public network. 

10 Description of the Prior Art 

11 Security is of primary concern in network communications, particularly transactions 
% : 3l2 taking place over the Internet. Highly sophisticated encryption algorithms have been employed 
l;jL3 to protect the integrity of sensitive data while in transit over public lines (transmission lines 
L : d4 subject to inspection). The encryption algorithms are typically so reliable that it has become 
TIJlS extremely difficult for an attacker to decipher a message that has been intercepted without access 
l % \6 . to the secret keys used to decrypt the message. Thus, attackers have focused their efforts on the 
: :i7 destination or source computers and software involved in the transaction, either by attempting to 
^18 intercept the message before encryption or after decryption, or by attempting to discover the 
C 3l9 secret keys used to decrypt the messages. 

20 For example, an attacker may attempt to steal a disk drive from a network and then read 

21 the stored data at their leisure. Storing the data in encrypted form protects against this type of 

22 attack since the data cannot be deciphered even if the disk drive is stolen. This, however, does 

23 not protect against an attacker monitoring the encryption process as it takes place on a computer 

24 connected to the disk drive. Computers and the software running thereon are typically 

25 susceptible to various types of probing, such as with debuggers or logic analyzers, as well as 

26 virus programs which may allow access to otherwise protected information. For example, a virus 

27 program may be introduced into a computer's operating system by attaching the virus to an 
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1 email. 

2 A paper by H. Gobioff, G. Gibson, and D. Tygar entitled "Security for Network Attached 

3 Storage Devices", October 23 1997, School of Computer Science, Carnegie Mellon University, 

4 suggests to implement the cryptographic circuitry and secret keys in tamper resistant circuitry 

5 within a disk drive where it is less susceptible to probing and virus attacks. These types of disk 

6 drives, referred to as NASD disk drives, are intended to be attached directly to a network in order 

7 to avoid the overhead associated with an intervening file server. 

8 An overview of the security aspects suggested for a NASD disk drive is shown in FIG. 

9 1A. A NASD disk drive 2 implements cryptography to communicate securely with a client 
10 computer 4 over a public network. Secret keys are used to encrypt and decrypt messages passed 

between the NASD disk drive 2 and client computer 4 so that any message intercepted in transit 

_^jl2 cannot be deciphered. In addition, the secret keys are used to transmit message authentication 

p-13 codes (MACs) which are used to verify the authenticity of the received messages. 
l'M4 To access the NASD disk drive 2, the client computer 4 sends a request 8, together with 

s 15 certain capability arguments, over a secure, private interface (not subject to inspection) to a file 

Ute manager computer 6. The file manager computer 6 generates a secret client key 10 based on a 
[117 * secret working key together with the capability arguments received from the client computer 4. 

f Jl8 The secret client key 10 is transferred to the client computer 4 over the secure interface. The 

19 client computer 4 constructs an encrypted message 12 together with a MAC using the secret 

20 client key 10, and the encrypted message 12, including the capability arguments, is transferred to 

21 the NASD disk drive 2 over a public interface. The NASD disk drive 2 uses the secret working 

22 key and the capability arguments received in the message in order to reconstruct the secret client 

23 key which is then used to decrypt the encrypted message 12 as well as verify its authentication 

24 using the MAC. The NASD disk drive 2 then uses the secret client key to construct an encrypted 

25 reply 14 (including a MAC) which is transferred to the client 4. The file manager computer 6 

26 may send a command 16 to the NASD disk drive 2 in order to change the secret working key, 

27 thereby decommissioning all of the previously issued secret client keys. 
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1 The above referenced paper suggests to implement the encryption, decryption, and 

2 message authentication facilities within the NASD disk drive 2 using tamper resistant circuitry to 

3 provide protection against probing attackers. However, the key management facilities 

4 implemented by the file manager computer 6 are still susceptible to attack, including physical 

5 probing attacks as well as attacks using virus programs which manipulate the operating system in 

6 OTder to reveal protected information concerning the secret keys. 

7 xhe Digital Transmission Content Specification or DTCP (available through the Internet 

8 at http:// www.dtcp . com ) discloses a cryptographic protocol for protecting audio/video (A/V) 

9 content from unauthorized copying as it traverses digital transmission mechanisms from device 
10 to device. Only compliant devices manufactured to support the DTCP protocol are capable of 

'31 transmitting or receiving the protected AAA content. Each device is manufactured with a unique 

l^l device ID and a public/private key pair which facilitate authentication and encryption/decryption 

s - hi of the A/V content. When a source device receives a request to transmit protected A/V content 

l ~ h4 to a sink device, the source and sink devices engage in an authentication transaction. If the 

= 15 authentication transaction is successful, the source device generates an exchange key which is 
nil 6 • communicated to the sink device. Tine exchange key is used by the sink device to generate a 

£117 * content key associated with each AA{ stream which is used to decrypt the A/V stream. 

□ 

pi 8 A problem with the DTCP protocol is that the A/V content is decrypted as it is received 

19 by the sink device and then stored on a storage medium in plaintext form. When the content is 

20 transferred to another device, the plaintext data is recovered from the storage medium, re- 

21 encrypted, transmitted, and again decrypted by the sink device for storage in plaintext form. 

22 Thus, the A/V content is only encrypted during transmission, which renders it susceptible to 

23 discovery by an attacker probing the devices. For example, an attacker may monitor the 

24 encryption or decryption process as they execute on a device, or an attacker may evaluate the 

25 storage medium in order to recover the A/V content in its plaintext form. 

26 U.S. Patent No. 5,931,947 discloses a network storage device for use in a secure array of 

27 such devices to support a distributed file system. Each device is an independent repository of 
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1 remotely encrypted data to be accessed by authorized network clients. All encryption is done by 

2 the clients, rather than by the devices, and the encrypted data is stored in encrypted form. Each 

3 network storage device comprises an owner key used to generate authentication keys within the 

4 device for authenticating messages received from the clients. However, the keys used by the 

5 clients for encrypting data and generating the message authentication codes are generated 

6 external to the devices by a system administrator which is susceptible to attack. 

7 There is, therefore, the need to improve security in network communications, particularly 

8 with respect to probing attacks and virus attacks on computer operating systems. 

9 SUMMARY OF THE INVENTION 

10 The present invention may be regarded as a secure disk drive comprising a disk for 

k 4\ storing data, and an input for receiving an encrypted message from a client disk drive, the 

l'-42 encrypted message comprising ciphertext data and a client drive ID identifying the client disk 

?"":13 drive. The secure disk drive comprises a secure drive key and an internal drive ID. A key 

!Hl4 generator within the secure disk drive generates a client drive key based on the client drive ED 

M5 and the secure drive key, and an internal drive key based on the internal drive ID and the secure 

Vh6 drive key. The secure disk drive further comprises an authenticator for verifying the authenticity 

ui 

□17 of the encrypted message and generating an enable signal, the authenticator is responsive to the 

t .1 

[118 encrypted message and the client drive key. The secure disk drive further comprises a data 

19 processor comprising a message input for receiving the encrypted message from the client disk 

20 drive, and a data output for outputting the ciphertext data to be written to the disk. The data 

21 processor further comprises an enable input for receiving the enable signal for enabling the data 

22 processor, and a key input for receiving the internal drive key, the internal drive key for use in 

23 generating a message authentication code. The data processor outputs reply data comprising the 

24 message authentication code. The secure disk drive outputs a reply to the client disk drive, the 

25 reply comprising the reply data and the internal drive ID. 

26 The present invention may also be regarded as a secure disk drive comprising a disk for 

27 storing data, and an input for receiving an encrypted message from a client disk drive, the 
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1 encrypted message comprising ciphertext data and a client drive ID identifying the client disk 

2 drive. The secure disk drive comprises a secure drive key and an internal drive ED. A key 

3 generator within the secure disk drive generates a client drive key based on the client drive ID 

4 and the secure drive key, and an internal drive key based on the internal drive ID and the secure 

5 drive key. The secure disk drive further comprises an authenticator for verifying the authenticity 

6 of the encrypted message and generating an enable signal, the authenticator is responsive to the 

7 encrypted message and the client drive key. The secure disk drive further comprises a data 

8 processor comprising a message input for receiving the encrypted message from the client disk 

9 drive, and a data input for receiving encrypted data read from the disk. The data processor 
10 further comprises an enable input for receiving the enable signal for enabling the data processor, 

and a key input for receiving the internal drive key, the internal drive key for use in generating a 

;jl2 message authentication code. The data processor outputs reply data comprising the encrypted 

0i3 data read from the disk and the message authentication code. The secure disk drive outputs a 

314 reply to the client disk drive, the reply comprising the reply data and the internal drive ID. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 
1^16 FIG. 1A shows an overview of a prior art network system wherein a file manager 

r 

jl7 performs key management functions for a Network Attached Storage Device (NASD). 

:?18 FIG. IB shows an overview of a computer network comprising a plurality of secure disk 

19 drives according to an embodiment of the present invention, wherein the secure disk drives 

20 implement key management and cryptographic functions for secure communication over the 

21 computer network, and the ciphertext data in the encrypted messages is not decrypted until 

22 presented to a trusted authority, such as a trusted client. 

23 FIG. 2 shows a secure disk drive according to an embodiment of the present invention as 

24 comprising a data processor for processing encrypted messages received from client disk drives, 

25 an authenticator for authenticating the encrypted messages and enabling the data processor to 

26 write the ciphertext data in the encrypted message to the disk, and a secure drive key and a drive 

27 ID for generating keys which facilitate cryptographic facilities such as authentication, encryption 
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1 and decryption. 

2 FIG. 3 shows a secure disk drive according to an embodiment of the present invention as 

3 comprising a data processor for processing encrypted messages received from client disk drives, 

4 an authenticator for authenticating the encrypted messages and enabling the data processor to 

5 read ciphertext data from the disk, and a secure drive key and a drive ID for generating keys 

6 which facilitate cryptographic facilities such as authentication, encryption and decryption. 

7 INSCRIPTION OF THE PREFERRED EMBODIMENTS 

8 FIG. 2 shows a secure disk drive 20 according to an embodiment of the present invention 

9 as comprising a disk 22 for storing data, and an input 24 for receiving an encrypted message 26 
10 from a client disk drive, the encrypted message 26 comprising cMiertext data and a client drive 

"Si ID identifying the client disk drive. The secure disk drive ^comprises a secure drive key 34 

J 11 2 and an internal drive ID 38. A key generator 30 within the'secure disk drive 20 generates a client 

; j ?l3 drive key 32 based on the client drive ID and the secjire drive key 34, and an internal drive key 

p!4 36 based on the internal drive ID 38 and the seci^arive key 34. The secure disk drive 20 further 

5 15 comprises an authenticator 56 for verifyine/fne authenticity of the encrypted message 26 and 

[ill 6 generating an enable signal 50, the authenticator 56 is responsive to the encrypted message 26 

□17 and the client drive key 32. The/secure disk drive further comprises a data processor 40 

[3I8 comprising a message input 42 &r receiving the encrypted message 26 from the client disk drive, 

19 and a data output 58 for outfitting the ciphertext data 46 to be written to the disk 22. The data 

20 processor 40 further comprises an enable input 48 for receiving the enable signal 50 for enabling 

21 the data processor ^40, and a key input 51 for receiving the internal drive key 36, the internal 

22 drive key 36 fo/use in generating a message authentication code. The data processor 40 outputs 

23 reply data/54 comprising the message authentication code. The secure disk drive 20 outputs a 

24 reply JoO to the client disk drive, the reply 60 comprising the reply data 54 and the internal drive 

25 ID/38. 

26 FIG. IB shows a computer network comprised of secure disk drives 64 and 66 which are 

27 manufactured to support the secure communication facilities according to the embodiments of 
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1 the present invention. Secure disk drive 64 comprises network communication circuitry for 

2 connecting directly to the network similar to the conventional NASD disk drive 2 of FIG. 1A, 

3 and secure disk drive 66 is connected to the network through a client computer 68. The network 

4 in the embodiment of FIG. IB further comprises a network file manager 70 for implementing a 

5 distributed file system which may utilize secure disk drives manufactured according to the secure 

6 communication facilities of the present invention. The data transmitted between the secure disk 

7 drives, including initial messages and replies, are encrypted to facilitate message authentication 

8 and secrecy. The secure disk drives may be connected directly, or they may be connected 

9 through intermediary computers, such as client, router, or server computers. In one embodiment, 
10 intermediary computers, such as the network file manager 70 and client computer 68 of FIG. IB, 

;Njl are intentionally isolated from the communication process so that the secure disk drives 

:'J.2 communicate autonomously. This embodiment protects against an attacker attempting to disrupt 

s fh3 the network by infiltrating an intermediary computer and masquerading as a trusted authority in 

44 order to invoke a denial of service facility. 

= 15 Communication between the secure disk drives involves transmitting encrypted messages 

[111 6 between the drives and authenticating the message as they are received. In one embodiment, the 

£317 secure disk drives comprise cryptographic facilities for encrypting the messages to be 

i. . j 

f ;jl 8 transmitted. For example, the secure disk drive 66 of FIG. IB may receive plaintext data from 

19 the client computer 68 which is encrypted into ciphertext, optionally stored, and then transmitted 

20 to another secure disk drive (e.g., secure disk drive 64). When an encrypted message is received 

21 by a secure disk drive, it is not automatically decrypted as with the prior art DTCP protocol. 

22 Instead, the ciphertext in the encrypted message is processed (e.g., stored) in its encrypted form 

23 in order to maintain the mathematical protection of the encryption algorithm, thereby protecting 

24 against a probing attacker who may, for example, steal the disk drive and analyze the storage 

25 medium at leisure. 

26 The embodiment of FIG. 2 illustrates a data transfer between two secure disk drives, 

27 wherein the secure disk drive 20 of FIG. 2 is receiving an encrypted message 26 from another 
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1 secure disk drive referred to as a client disk drive. The encrypted message 26 comprises 

2 ciphertext data which is to be written to the disk 22. Before executing the write operation, 

3 however, the authenticator 56 within the secure disk drive 20 first authenticates the encrypted 

4 message 26 to verify that it has been received from a secure disk drive belonging to a trusted 

5 nexus of secure disk drives, and that the encrypted message 26 has not been tampered with 

6 during transmission. In one embodiment, the authenticator 56 also verifies the access rights 

7 associated with the encrypted message 26 received from the client disk drive. To facilitate the 

8 authentication process, each secure disk drive is manufactured with a unique drive ID 38 and a 

9 secure drive key 34. When an encrypted message is output from a secure disk drive, a message 
10 authentication code is generated using an internal drive key 36. The internal drive key 36 is 

1*41 generated by the key generator 30 based on the unique drive ID 38 and the secure drive key 34. 

J; -4 2 The encrypted message 26 also contains the unique drive ID of the client disk drive so that the 

^3 secure disk drive 20 receiving the encrypted message 26 can identify the client disk drive (the 

^14 sender of the encrypted message 26). 

I \5 The message authentication code may be implemented using any suitable technique. For 

till 6 example, in one embodiment the message authentication code is generated using well known 



pi 7 hash message authentication codes or HMACs. In another embodiment, the encrypted message 



pi 8 is self authenticating in that it can only be decrypted if it has been generated by a trusted 

19 authority and has not been modified during the transmission. In yet another embodiment, the 

20 authentication process involves a challenge and response sequence between the secure disk 

21 drives. The authenticator 56 of FIG.2 comprises suitable means for implementing the 

22 authentication facility. 

23 The client drive ID received in the encrypted message 26 may be encrypted, but it is 

24 ultimately presented to the key generator 30 in plaintext form. The key generator 30 generates a 

25 client drive key 32 based on the client drive ID and the secure drive key 34 of the receiving 

26 secure disk drive 20. The client drive key 32 may be symmetric or asymmetric depending on the 

27 design of the message authentication code. The authenticator 56 evaluates the client drive ED in 
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1 the encrypted message 26 to verify that the client disk drive is part of the trusted nexus and has 

2 not been decommissioned. The authenticator 56 then uses the client drive key 32 to verify that 

3 the encrypted message 26 was in fact generated by the client disk drive which is associated with 

4 the client drive ID received in the encrypted message 26. In addition, the authenticator 56 may 

5 use the client drive key 32 to verify that the encrypted message 26 was not modified during the 

6 transmission. For example, if the message authentication code is generated using an HMAC over 

7 the entire encrypted message, then the corresponding HMAC generated by the authenticator 56 

8 will not authenticate the message if the message is modified during the transmission or if the 

9 message is transmitted by an invalid entity. 

10 If a received message fails to authenticate, it may indicate the secure disk drive that 

1 1 transmitted the message has been tampered with. In one embodiment, steps are taken to evaluate 

12 the integrity of the secure disk drive to determine if it has been compromised. For example, the 

13 file manager 70 of FIG. IB or another secure disk drive may initiate a challenge and response 

14 verification sequence with the suspect secure disk drive. If the secure disk drive fails the 

15 challenge and response verification sequence, it is deemed compromised and is decommissioned. 

16 In an alternative embodiment, the secure disk drives are designed to detect internal tampering 

17 and will decommission themselves from the nexus when internal tampering is detected. The 

18 decommissioning function may be implemented by the file manager 70, or it may be distributed 

19 and handled autonomously by the nexus of secure disk drives. In one embodiment, a message is 

20 transmitted to the nexus of secure disk drives indicating that a compromised secure disk drive 

21 has been decommissioned. 

22 If the authenticator 56 authenticates the encrypted message 26, then the secure disk drive 

23 20 of FIG. 2 extracts the ciphertext data 46 from the encrypted message 26 and writes it to the 

24 disk 22. In one embodiment, the data processor 40 comprises error correction code (ECC) 

25 facilities for generating redundancy symbols appended to the ciphertext data 46 as it is written to 

26 the disk 22. The redundancy symbols are used during read-back to correct errors induced by the 

27 recording process. 
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1 After completing the write operation, the secure disk drive 20 of FIG. 2 generates an 

2 encrypted reply 60 transmitted to the client disk drive to confirm that the write operation was 

3 executed successfully. The key generator 30 generates an internal drive key 36 using the secure 

4 drive key 34 and the drive ID 38. The data processor 40 generates reply data 54 (indicating a 

5 successful write operation) and uses the internal drive key 36 to generate a message 

6 authentication code over the reply data. The reply data (including the message authentication 

7 code) together with the drive ID 38 are then transmitted to the client disk drive as the encrypted 

8 reply 60 via output 58. In the embodiment shown in FIG. 2, a multiplexer 62 first applies the 

9 reply data 54 to the output 58 and then applies the drive ID 38 to the output 58. The data 
10 processor 40 may also encrypt the reply data 54 before transmitting it to the client disk drive. 

a. 

jll The key generator 30 comprises suitable facilities for generating the client drive key 32 

^12 and the internal drive key 36. For example, in one embodiment the key generator 30 generates 

3.13 the keys using well known hash functions, such as those disclosed in the MD5 Message Digest 

114 Algorithm. The secure drive key 34 may be mutable in order to reconfigure a nexus of secure 

a 

15 disk drives, wherein the key generator 30 computes the internal drive key 36 dynamically each 

%\6 time it is needed by the data processor 40. In another embodiment, the secure drive key 34 is 

^17 immutable and the internal drive key 36 is also static (i.e., computed one time and stored 

Jl8 securely). In yet another embodiment, the secure drive key 34 is immutable but the internal drive 

19 key 36 is computed dynamically so that it is generated only if the secure disk drive 20 is 

20 operating correctly. 

21 FIG. 3 illustrates a secure disk drive 72 according to an embodiment of the present 

22 invention wherein the encrypted message 26 comprises a read request generated by the client 

23 disk drive. The data processor 40 comprises a message input 42 for receiving the encrypted 

24 message 26 from the client disk drive, and a data input 64 for receiving ciphertext data 74 read 

25 from the disk 22. The data processor 40 further comprises an enable input 48 for receiving the 

26 enable signal 50 for enabling the data processor 40, and a key input 51 for receiving the internal 

27 drive key 36, the internal drive key 36 for use in generating a message authentication code. The 
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1 data processor 40 outputs reply data 54 comprising the ciphertext data 74 read from the disk 22 

2 and the message authentication code. The secure disk drive 72 outputs an encrypted reply 60 to 

3 the client disk drive, the encrypted reply 60 comprising the reply data 54 and the internal drive 

4 ID 38. In one embodiment, the secure disk drive 72 further comprises cryptographic facilities for 

5 decrypting the ciphertext data 74 into plaintext data which is supplied to a trusted authority. 

6 The components in the secure disk drive 20 shown in FIG. 2 may be implemented in 

7 integrated circuitry or in firmware executed by a microprocessor. In one embodiment, tamper- 

8 resistant circuitry is used to implement one or more of the components, such as the secure drive 

9 key 34, the key generator 30, and/or the authenticator 56, in order to protect against a probing 

10 attacker from deriving information about the secure drive key 34. An example discussion of 

11 tamper-resistant circuitry is provided in Tygar, J.D. and Yee, B.S., "Secure Coprocessors in 

12 Electronic Commerce Applications," Proceedings 1995 USENIX Electronic Commerce 

13 Workshop, 1995, New York, which is incorporated herein by reference. Further, implementing 

14 the key management, authentication and cryptographic facilities wholly within the secure disk 

15 drive autonomous from the operating system of a host computer renders the network less 

16 susceptible to virus attacks as compared to the file manager computer 6 in the prior art NASD 

17 implementation shown in FIG. 1A. 
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